# 롤백

## 개요

**롤백**(Rollback)은 소프트웨어 배포, 데이터베이스 트랜잭션, 시스템 구성 변경 등 다양한 기술 분야에서 사용되는 핵심 개념으로, 이전의 안정적인 상태로 시스템을 되돌리는 절차를 의미합니다. 특히 **배포 관리** 맥락에서 롤백은 새로운 버전의 소프트웨어 배포 후 예기치 못한 오류, 성능 저하, 보안 취약점 등의 문제가 발생했을 때, 서비스의 정상 동작을 보장하기 위해 이전 버전으로 신속하게 복귀하는 전략적 수단입니다.

롤백은 시스템의 **가용성**, **신뢰성**, **사용자 경험**을 보호하는 데 중요한 역할을 하며, 현대의 DevOps 및 지속적 통합/지속적 배포(CI/CD) 환경에서 필수적인 프로세스로 간주됩니다.

---

## 롤백의 목적과 필요성

### 1. 안정성 확보
새로운 소프트웨어 버전을 배포하면 기능 개선이나 버그 수정이 이루어지지만, 동시에 새로운 오류가 발생할 수 있습니다. 롤백은 이러한 위험을 최소화하고, 시스템이 **이전의 검증된 상태**로 되돌아가게 함으로써 서비스 중단 시간(MTTR, Mean Time to Recovery)을 줄입니다.

### 2. 사용자 영향 최소화
배포로 인한 장애가 사용자에게 직접적인 영향을 미칠 수 있습니다. 예를 들어, 웹사이트의 주요 기능이 동작하지 않거나, 모바일 앱이 크래시하는 경우, 빠른 롤백을 통해 사용자 불만과 신뢰도 저하를 방지할 수 있습니다.

### 3. CI/CD 파이프라인의 안정성 강화
자동화된 배포 환경에서는 롤백이 실패 대응 전략의 일환으로 통합됩니다. 모니터링 시스템이 배포 후 이상 징후를 감지하면 자동으로 롤백을 트리거할 수 있어, 운영 팀의 개입 없이도 빠르게 복구가 가능합니다.

---

## 롤백의 주요 유형

### 1. 코드 기반 롤백 (Code Rollback)
소프트웨어 배포 후 문제가 발생했을 때, 이전 버전의 코드를 다시 배포하는 방식입니다. 일반적으로 소스 코드 관리 시스템(Git 등)에서 이전 커밋으로 되돌아가 빌드 및 배포를 재수행합니다.

**예시:**
```bash
git checkout HEAD~1  # 이전 커밋으로 체크아웃
git push origin main # 다시 배포
```

### 2. 데이터베이스 롤백 (Database Rollback)
데이터베이스 스키마 변경이나 대량 데이터 마이그레이션 중 오류가 발생했을 때, 트랜잭션을 취소하거나 백업에서 데이터를 복원하는 방식입니다. 주로 **트랜잭션 롤백**(ROLLBACK 명령어) 또는 **백업 복구**를 통해 수행됩니다.

```sql
BEGIN TRANSACTION;
UPDATE users SET status = 'active' WHERE id = 1;
-- 오류 발생 시
ROLLBACK; -- 변경 사항 취소
```

### 3. 구성 파일 롤백 (Configuration Rollback)
서버 설정, 환경 변수, 인프라 구성(YAML, JSON 등) 변경으로 인해 시스템이 불안정해졌을 경우, 이전 구성 파일을 재적용하는 방식입니다. 인프라를 코드로 관리(IaC)하는 도구(Terraform, Ansible 등)에서는 버전 관리 기능을 통해 쉽게 롤백 가능합니다.

---

## 롤백 전략

### 1. 수동 롤백 (Manual Rollback)
운영자가 직접 문제를 인지하고, 수동으로 이전 버전을 배포하는 방식입니다. 간단하지만 반응 속도가 느릴 수 있으며, 인적 오류의 위험이 있습니다.

### 2. 자동 롤백 (Automated Rollback)
모니터링 도구(Grafana, Prometheus, Datadog 등)가 CPU 사용률, 오류율, 응답 지연 시간 등의 지표를 실시간으로 감시하고, 기준치를 초과하면 자동으로 롤백을 실행합니다. CI/CD 도구(Jenkins, GitLab CI, Argo CD 등)와 연동되어 자동화된 파이프라인에서 흔히 사용됩니다.

**예시 (GitLab CI 설정):**
```yaml
deploy:
  script:
    - deploy.sh
  environment: production
  on_failure:
    - rollback.sh  # 배포 실패 시 자동 실행
```

### 3. 블루-그린 배포와 롤백
블루-그린 배포는 두 개의 동일한 환경(Blue: 기존, Green: 새 버전)을 유지하고 트래픽을 점진적으로 전환하는 방식입니다. 롤백이 필요할 경우, 트래픽을 즉시 기존 환경(Blue)으로 되돌리기만 하면 되므로 **매우 빠르고 안전한 롤백**이 가능합니다.

### 4. 카나리 배포와 롤백
소수의 사용자에게만 새 버전을 배포하여 안정성을 검증한 후 점진적으로 확대하는 방식입니다. 문제가 발생하면 해당 사용자 그룹만 영향을 받으며, 나머지 사용자는 기존 버전을 계속 이용할 수 있어 **영향 범위를 최소화**하고 빠르게 롤백할 수 있습니다.

---

## 롤백 고려사항

- **버전 호환성**: 롤백 시 이전 버전과 현재 데이터 또는 외부 시스템 간의 호환성이 유지되어야 합니다.
- **데이터 무결성**: 데이터베이스 스키마 변경 후 롤백 시, 데이터 손실이나 구조 불일치를 방지해야 합니다.
- **문서화 및 로깅**: 롤백 수행 시기를 기록하고, 그 원인과 절차를 문서화하여 향후 분석에 활용해야 합니다.
- **테스트 환경에서의 검증**: 실제 운영 환경에서 롤백을 시도하기 전, 테스트 환경에서 절차를 검증하는 것이 중요합니다.

---

## 관련 도구 및 기술

| 도구 | 역할 |
|------|------|
| **Git** | 코드 버전 관리 및 롤백 기반 제공 |
| **Docker/Kubernetes** | 컨테이너 이미지 태그를 통해 이전 버전 재배포 |
| **Terraform** | 인프라 구성 롤백 및 상태 관리 |
| **Prometheus + Alertmanager** | 이상 감지 및 자동 롤백 트리거 |
| **Argo Rollouts** | 카나리, 블루-그린 배포 및 자동 롤백 기능 제공 |

---

## 참고 자료

- Martin Fowler, "Blue-Green Deployment", [https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html)
- Google SRE 책, "Site Reliability Engineering", O'Reilly
- GitLab CI/CD 문서: [https://docs.gitlab.com/ee/ci/](https://docs.gitlab.com/ee/ci/)
- Kubernetes Deployment Rollback: `kubectl rollout undo deployment/<name>`

---

롤백은 단순한 ‘되돌리기’ 이상의 전략적 프로세스입니다. 철저한 계획, 자동화, 모니터링과 결합될 때 비로소 안정적인 소프트웨어 운영 환경을 구축할 수 있습니다. 따라서 모든 배포는 반드시 롤백 계획을 수반해야 하며, 이를 통해 시스템의 회복력과 신뢰성을 극대화할 수 있습니다.